1. Technical Field of the Invention
The present invention relates to apparatus and methods for processing buffered data.
2. Description of Related Art
There is an increasing number of applications in which data is transferred between a transmitter and a receiver as a plurality of data streams over a single logical link. The data streams can be segmented at the transmitter into packets, each of which contains some data from the data streams. Usually, but not necessarily, each packet contains data from only one of the data streams. The packets are then transmitted independently over the link. When the packets are received at the receiver they are reassembled so as to re-form the data streams. Advantages of this system over conventional analog techniques are that there is no need for a dedicated link or channel to be assigned to each of the data streams; that interference in transmission may affect only some of the packets, leaving some data streams unaffected; and that packets may be routed to the receiver over any available physical link and still combined properly to re-form the data streams even if the packets arrive out of order.
Each packet normally includes control data that allows the packet to be re-assembled properly by the receiver. This may comprise data indicating the data stream whose data is included in the packet, and a serial number for the packet so that the packet can be combined in the correct order with others from that data stream. The control data can also comprise error check data such as a checksum for allowing the receiver to verify that the packet has not been corrupted during transmission.
One application for the above technology is in the delivery of digital video signals to households via cable or satellite links. Digital video streams may be packetized and then broadcast to household receivers. A user of a receiver may then select one of the streams for viewing. The receiver can then reassemble that video stream from the received packets, convert it to a form suitable for input to the user's television and then output the resulting signal to the television. It has been proposed that such systems could offer additional features. These features include the storing of received streams for later viewing, and the displaying of program guides (lists of programs with transmission times) which could be assembled by the receiver from certain transmitted packets.
FIG. 1 shows the transport packet stream syntax specified in ITU-T standard H.222.0, equivalent to ISO/IEC standard 138181. (Further detail of the structure is available from the standard itself, the contents of which are incorporated herein by reference). FIG. 1 is equivalent to annex F.0.1 of the H.222 standard. The transport stream 1 comprises a stream of packets, each of which consists of 188 bytes. Each packet has a variable length header illustrated at 2 and a payload which occupies the remainder of the packet. The header has the following structure:
Number of bitsSignification8Synchronisation byte1Transport error indicator1Payload unit start indicator1Transport priority13 Program Identification (PID)2Transport scrambling control2Adaptation field control4Continuity counterVariableAdaptation field
The structure of the adaptation field is shown in more detail in FIG. 1.
Data representing video, audio, system information such as program guides and other user data streams can be carried as PES packets, which can be included in the payloads of the transport stream packets. The structure of a PES packet is shown in FIG. 2. FIG. 2 is equivalent to annex F.0.2 of the H.222 standard. Each PES packet comprises a 24 bit packet start code prefix, an 8 bit stream identification, 16 bits indicating the length of the PES packet, an optional variable length PES header and PES packet data of variable length.
FIG. 3 shows that the PES packets together form part of a program stream, whose structure is shown in FIG. 3. FIG. 3 is equivalent to annex F.0.7 of the H.222 standard.
In addition, section data can be carried in the packets. The section data can include information that is to be interpreted by the decoding unit. For example, section data may include:
1. data that is to be assembled by the receiving unit into a program guide indicating the programs that are to be provided on a channel;
2. data that is to be assembled into code that can be executed by an interpreter (an “o-code interpreter”) in the receiving unit; and/or
3. data that is to be assembled into decoding keys to allow the receiving unit to decrypt encoded data transmissions such as pay-per-view video.
The overall structure of an H.222 packet containing section data is summarized in FIG. 4, which shows schematically some important features of the packet. The packet comprises a header 5, an adaptation field 6 and a payload 7. The header includes a payload unit start bit 8 and a program identifier (PID) 9. The payload includes one or more sections 10 and, if the payload unit start bit is set, a pointer field 11 which indicates the offset x to the start of the first new section (the intervening bits of the packet may represent tail data of a preceding section). Each section includes information giving the length of that block, and periodically a section includes CRC (cyclic redundancy check) data for it, in order for the receiver to check that section has been correctly received.
A receiving unit can check that a contiguous group of blocks of data forming a section has been received correctly, by calculating a CRC value for the section once it has been received and comparing the calculated CRC value with the received CRC data or, for example, a preset value. If there is the required match then it is assumed that the data has been received correctly. If there is not the required match then the whole section as received is discarded. Retransmission of the section may then be requested, or the receiver may assume that the incorrectly received section has been lost and continue by receiving the next section. In one such checking method a counter is maintained at the receiver, with an initial value of −1. Every incoming byte is combined in turn with the value in the counter to create a new value. The 4 bytes of CRC data at the end of a section are of the values such that if they and the rest of the section have been correctly received then after those 4 bytes have been combined in turn with the counter the value of the counter will be zero. A final value in the counter that does not match zero indicates that data has been corrupted.
When data is received it is conveniently stored in a circular buffer. The circular buffer is defined by a series of memory locations together with a pair of pointers indicating the current locations at which data should be written and from which data should be read in the buffer. The pointers are wrapped at the boundaries of the span of the memory locations so as to give the buffer its circular nature.
The consumer of data from the buffer updates the read pointer after taking data out of a buffer, and the write is updated after placing data in a buffer. However, this approach has the problem that if data is multiplexed and can span several transport packets, a buffer may have data added to it over a long period of time before an entire section or PES packet has been collected. If an error is discovered within the transport stream the PES packet or section may be in error.